SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
C

C static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C code

  • All rules 420
  • Vulnerability14
  • Bug111
  • Security Hotspot19
  • Code Smell276

  • Quick Fix 27
 
Tags
    Impact
      Clean code attribute
        1. "goto" should jump to labels declared later in the same function

           Code Smell
        2. Pointer and reference parameters should be "const" if the corresponding object is not modified

           Code Smell
        3. "<time.h>" should not be used

           Code Smell
        4. "<stdio.h>" should not be used in production code

           Code Smell
        5. "offsetof" macro should not be used

           Code Smell
        6. "errno" should not be used

           Code Smell
        7. "setjmp" and "longjmp" should not be used

           Code Smell
        8. Reserved identifiers should not be defined or declared

           Code Smell
        9. Only standard forms of the "defined" directive should be used

           Code Smell
        10. Preprocessor operators "#" and "##" should not be used

           Code Smell
        11. There shall be at most one occurrence of the # or ## operators in a single macro definition

           Code Smell
        12. In the definition of a function-like macro, each instance of a parameter shall be enclosed in parentheses, unless it is used as the operand of # or ##

           Code Smell
        13. Function-like macros should not be used

           Code Smell
        14. "#undef" should be used with caution

           Code Smell
        15. Macros should not be #define'd or #undef'd within a block

           Code Smell
        16. #include directives in a file should only be preceded by other preprocessor directives or comments

           Code Smell
        17. Unions should not be used

           Code Smell
        18. Structure and union types should be complete at the end of a translation unit

           Code Smell
        19. Object declarations should contain no more than 2 levels of pointer indirection

           Code Smell
        20. Function names should be used either as a call with a parameter list or with the "&" operator

           Code Smell
        21. Functions without parameters should be declared with parameter type "void"

           Code Smell
        22. Parameters in a function prototype should be named

           Code Smell
        23. Recursion should not be used

           Code Smell
        24. Loops should not have more than one "break" or "goto" statement

           Code Smell
        25. Functions should not be defined with a variable number of arguments

           Code Smell
        26. Switch statement conditions should not have essentially boolean type

           Code Smell
        27. Switch labels should not be nested inside non-switch blocks

           Code Smell
        28. The right-hand operands of && and || should not contain side effects

           Code Smell
        29. "continue" should not be used

           Code Smell
        30. "goto" statement should not be used

           Code Smell
        31. Unused type declarations should be removed

           Code Smell
        32. The three expressions of a "for" statement should only be concerned with loop control

           Code Smell
        33. Tests of non-Boolean values against zero should be explicit

           Code Smell
        34. Increment (++) and decrement (--) operators should not be used in a method call or mixed with other operators in an expression

           Code Smell
        35. Comma operator should not be used

           Code Smell
        36. "enum" values should not be used as operands to built-in operators other than [ ], =, ==, !=, unary &, and the relational operators <, <=, >, >=

           Code Smell
        37. "bool" expressions should not be used as operands to built-in operators other than =, &&, ||, !, ==, !=, unary &, and the conditional operator

           Code Smell
        38. Operands of "&&" and "||" should be primary (C) or postfix (C++) expressions

           Code Smell
        39. Limited dependence should be placed on operator precedence

           Code Smell
        40. A cast shall not remove any const or volatile qualification from the type of a pointer or reference

           Code Smell
        41. Constants of unsigned type should have a "U" suffix

           Code Smell
        42. The value of a complex expression should only be cast to a type that is narrower and of the same signedness as the underlying type of the expression

           Code Smell
        43. Signed and unsigned types should not be mixed in expressions

           Code Smell
        44. "enum" members with implicit values should not collide with other enumerators

           Code Smell
        45. Braces should be used to indicate and match the structure in the non-zero initialization of arrays and structures

           Code Smell
        46. Array declarations should include an explicit size specification

           Code Smell
        47. If a function has internal linkage then all re-declarations shall include the static storage class specifer

           Code Smell
        48. Functions should not be declared at block scope

           Code Smell
        49. Non-standard attributes should not be used

           Code Smell
        50. Object and function types should be explicitly stated in their declarations and definitions

           Code Smell
        51. Functions should be declared explicitly

           Code Smell
        52. Literal suffix "L" for long integers shall be upper case

           Code Smell
        53. Bit fields should be declared with appropriate types

           Code Smell
        54. typedefs that indicate size and signedness should be used in place of the basic types

           Code Smell
        55. Appropriate char types should be used for character and integer values

           Code Smell
        56. Identifiers should not be longer than 31 characters

           Code Smell
        57. Digraphs should not be used

           Code Smell
        58. Trigraphs should not be used

           Code Smell
        59. All uses of the #pragma directive should be documented

           Code Smell
        60. Source code should only use /* ... */ style comments

           Code Smell
        61. Assembly language should be encapsulated and isolated

           Code Smell
        62. The first element of an array should not be accessed implicitly

           Code Smell
        63. A single L in a literal suffix should only be used for long values

           Code Smell
        64. Names of well-known C standard library macros and functions should not be used as identifiers

           Code Smell
        65. All the elements of an aggregate should be provided with an initial value

           Code Smell
        66. Multicharacter literals should not be used

           Code Smell
        67. Loop variables should be declared in the minimal possible scope

           Code Smell
        68. Macros should not be used as replacements for "typedef" and "using"

           Code Smell
        69. Track comments matching a regular expression

           Code Smell
        70. Functions that are not used in a project should be removed

           Code Smell
        71. Size of bit fields should not exceed the size of their types

           Code Smell
        72. Only valid arguments should be passed to UNIX/POSIX functions

           Code Smell
        73. Only valid arguments should be passed to stream functions

           Code Smell
        74. "^" should not be confused with exponentiation

           Code Smell
        75. Pointer and reference local variables should be "const" if the corresponding object is not modified

           Code Smell
        76. Blocking functions should not be called inside critical sections

           Code Smell
        77. Return value of "setuid" family of functions should always be checked

           Code Smell
        78. GNU attributes should be used correctly

           Code Smell
        79. Format strings should comply with ISO standards

           Code Smell
        80. Size of variable length arrays should be greater than zero

           Code Smell
        81. Argument of "printf" should be a format string

           Code Smell
        82. "mktemp" family of functions templates should have at least six trailing "X"s

           Code Smell
        83. Unevaluated operands should not have side effects

           Code Smell
        84. Size argument of memory functions should be consistent

           Code Smell
        85. Return value of "nodiscard" functions should not be ignored

           Code Smell
        86. Implicit casts should not lower precision

           Code Smell
        87. Appropriate size arguments should be passed to "strncat" and "strlcpy"

           Code Smell
        88. Functions which do not return should be declared as "noreturn"

           Code Smell
        89. Keywords shall not be used as macros identifiers

           Code Smell
        90. Logical operators should not be confused with bitwise operators

           Code Smell
        91. Dereferenced null pointers should not be bound to references

           Code Smell
        92. "else" statements should be clearly matched with an "if"

           Code Smell
        93. Header guards should be followed by a matching "#define" macro

           Code Smell
        94. "default" clauses should be first or last

           Code Smell
        95. Include directives should not rely on non-portable search strategy

           Code Smell
        96. A conditionally executed single line should be denoted by indentation

           Code Smell
        97. Conditionals should start on new lines

           Code Smell
        98. "case" ranges should cover multiple values

           Code Smell
        99. "#include" paths should be portable

           Code Smell
        100. "#import" should not be used

           Code Smell
        101. Cognitive Complexity of functions should not be too high

           Code Smell
        102. Macros should not be redefined

           Code Smell
        103. "#include_next" should not be used

           Code Smell
        104. Array indices should be placed between brackets

           Code Smell
        105. String literals should not be concatenated implicitly

           Code Smell
        106. GNU extensions should not be used

           Code Smell
        107. Local variables should not be volatile

           Code Smell
        108. Types and variables should be declared in separate statements

           Code Smell
        109. "switch" statements should cover all cases

           Code Smell
        110. Redundant pointer operator sequences should be removed

           Code Smell
        111. Empty "case" clauses that fall through to the "default" should be omitted

           Code Smell
        112. Format strings should be used correctly

           Code Smell
        113. Conditional operators should not be nested

           Code Smell
        114. Forward declarations should not be redundant

           Code Smell
        115. Label names should comply with a naming convention

           Code Smell
        116. Bit fields should not be used

           Code Smell
        117. Declarations should not be empty

           Code Smell
        118. Multiline blocks should be enclosed in curly braces

           Code Smell
        119. Increment should not be used to set boolean variables to 'true'

           Code Smell
        120. Control characters should not be used in literals

           Code Smell
        121. Enumeration values should comply with a naming convention

           Code Smell
        122. Enumeration names should comply with a naming convention

           Code Smell
        123. Octal and hexadecimal escape sequences should be terminated

           Code Smell
        124. Flexible array members should not be declared

           Code Smell
        125. Track parsing failures

           Code Smell
        126. User-specified functions should not be called

           Code Smell
        127. Parameters should be passed in the correct order

           Code Smell
        128. Comment styles "//" and "/* ... */" should not be mixed within a file

           Code Smell
        129. Preprocessor directives should not be indented

           Code Smell
        130. Track instances of the "#error" preprocessor directive being reached

           Code Smell
        131. Non-reentrant POSIX functions should be replaced with their reentrant versions

           Code Smell
        132. Obsolete POSIX functions should not be used

           Code Smell
        133. "goto" statements should not be used to jump into blocks

           Code Smell
        134. Redundant casts should not be used

           Code Smell
        135. "union" names should comply with a naming convention

           Code Smell
        136. Code annotated as deprecated should not be used

           Code Smell
        137. Two branches in a conditional structure should not have exactly the same implementation

           Code Smell
        138. Unused assignments should be removed

           Code Smell
        139. "restrict" should not be used

           Code Smell
        140. "static" should not be used for the size of an array parameter

           Code Smell
        141. "switch" statements should not be nested

           Code Smell
        142. Structures should not have too many fields

           Code Smell
        143. The ternary operator should not be used

           Code Smell
        144. Constants should come first in equality tests

           Code Smell
        145. The sign of an unsigned variable should not be tested

           Code Smell
        146. "#pragma warning (default: ...)" should not be used

           Code Smell
        147. Pre-defined macros should not be defined, redefined or undefined

           Code Smell
        148. Keywords introduced in later specifications should not be used as identifiers

           Code Smell
        149. Type specifiers should be listed in a standard order

           Code Smell
        150. Track "TODO" and "FIXME" comments that do not contain a reference to a person

           Code Smell
        151. The prefix increment/decrement form should be used

           Code Smell
        152. Multiple variables should not be declared on the same line

           Code Smell
        153. "struct" names should comply with a naming convention

           Code Smell
        154. File names should comply with a naming convention

           Code Smell
        155. Macro names should comply with a naming convention

           Code Smell
        156. Cyclomatic Complexity of functions should not be too high

           Code Smell
        157. Unused local variables should be removed

           Code Smell
        158. "switch" statements should not have too many "case" clauses

           Code Smell
        159. Track lack of copyright and license headers

           Code Smell
        160. Comments should not be located at the end of lines of code

           Code Smell
        161. Functions/methods should not have too many lines

           Code Smell
        162. Control flow statements "if", "for", "while", "switch" and "try" should not be nested too deeply

           Code Smell
        163. Octal values should not be used

           Code Smell
        164. "switch" statements should have "default" clauses

           Code Smell
        165. "if" statements should be preferred over "switch" when simpler

           Code Smell
        166. Track uses of "NOSONAR" comments

           Code Smell
        167. Switch cases should end with an unconditional "break" statement

           Code Smell
        168. "for" loop stop conditions should be invariant

           Code Smell
        169. A "while" loop should be used instead of a "for" loop

           Code Smell
        170. "if ... else if" constructs should end with "else" clauses

           Code Smell
        171. "typedef" should be used for function pointers

           Code Smell
        172. Sections of code should not be commented out

           Code Smell
        173. break statements should not be used except for switch cases

           Code Smell
        174. Statements should be on separate lines

           Code Smell
        175. "switch" statements should not contain non-case labels

           Code Smell
        176. Control structures should use curly braces

           Code Smell
        177. Nested code blocks should not be used

           Code Smell
        178. Deprecated K&R syntax should not be used for function definition

           Code Smell
        179. Methods should not be empty

           Code Smell
        180. Unused function parameters should be removed

           Code Smell
        181. Local variable and function parameter names should comply with a naming convention

           Code Smell
        182. Field names should comply with a naming convention

           Code Smell
        183. "switch case" clauses should not have too many lines of code

           Code Smell
        184. Unused functions and methods should be removed

           Code Smell
        185. Functions should not contain too many return statements

           Code Smell
        186. Track uses of "TODO" tags

           Code Smell
        187. Track uses of "FIXME" tags

           Code Smell
        188. Deprecated code should be removed

           Code Smell
        189. Lines should not end with trailing whitespaces

           Code Smell
        190. Files should end with a newline

           Code Smell
        191. Deprecated attributes should include explanations

           Code Smell
        192. Assignments should not be made from within conditions

           Code Smell
        193. Variables should not be shadowed

           Code Smell
        194. Empty statements should be removed

           Code Smell
        195. Redundant pairs of parentheses should be removed

           Code Smell
        196. "/*" and "//" should not be used within comments

           Code Smell
        197. Magic numbers should not be used

           Code Smell
        198. Nested blocks of code should not be left empty

           Code Smell
        199. Functions should not have too many parameters

           Code Smell
        200. Expressions should not be too complex

           Code Smell
        201. Mergeable "if" statements should be combined

           Code Smell
        202. Unused labels should be removed

           Code Smell
        203. Tabulation characters should not be used

           Code Smell
        204. Files should not have too many lines of code

           Code Smell
        205. Control should not be transferred into a complex logic block using a "goto" or a "switch" statement

           Code Smell
        206. Lines should not be too long

           Code Smell
        207. A function should have a single point of exit at the end of the function

           Code Smell
        208. Function names should comply with a naming convention

           Code Smell
        209. The "goto" statement should not be used

           Code Smell
        210. An "integer-literal" of type "long long" shall not use a single "L" or "l" in any suffix

           Code Smell
        211. The literal value zero shall be the only value assigned to "errno"

           Code Smell
        212. User-defined identifiers shall have an appropriate form

           Code Smell
        213. "Global variables" shall not be used

           Code Smell
        214. The built-in unary "+" operator should not be used

           Code Smell
        215. "Integral promotion" and the "usual arithmetic conversions" shall not change the signedness or the "type category" of an operand

           Code Smell
        216. The argument to a "mixed-use macro parameter" shall not be subject to further expansion

           Code Smell
        217. An "object pointer type" shall not be cast to an integral type other than "std::uintptr_t" or "std::intptr_t"

           Code Smell
        218. Functions with "limited visibility" should be "used" at least once

           Code Smell
        219. All variables should be initialized

           Code Smell
        220. Octal escape sequences, hexadecimal escape sequences and universal character names shall be terminated

           Code Smell
        221. Dynamic memory shall be managed automatically

           Code Smell
        222. Local variables shall not have static storage duration

           Code Smell
        223. The facilities provided by the standard "header file" "<csignal>" shall not be used

           Code Smell
        224. "Dynamic memory" should not be used

           Code Smell
        225. The macro "offsetof" shall not be used

           Code Smell
        226. The standard "header file" "<csetjmp>" shall not be used

           Code Smell
        227. The "#pragma" directive and the "_Pragma" operator should not be used

           Code Smell
        228. The "#" and "##" preprocessor operators should not be used

           Code Smell
        229. A macro parameter immediately following a "#" operator shall not be immediately followed by a "##" operator

           Code Smell
        230. Precautions shall be taken in order to prevent the contents of a "header file" being included more than once

           Code Smell
        231. All "#else", "#elif" and "#endif" preprocessor directives shall reside in the same file as the "#if", "#ifdef" or "#ifndef" directive to which they are related

           Code Smell
        232. Program-terminating functions should not be used

           Code Smell
        233. A bit-field shall have an appropriate type

           Code Smell
        234. Bit-fields should not be declared

           Code Smell
        235. Within an enumerator list, the value of an implicitly-specified "enumeration constant" shall be unique

           Code Smell
        236. A conversion from function type to pointer-to-function type shall only occur in appropriate contexts

           Code Smell
        237. The parameters in all "declarations" or overrides of a function shall either be unnamed or have identical names

           Code Smell
        238. The features of "<cstdarg>" shall not be used

           Code Smell
        239. A "declaration" should not declare more than one variable or member variable

           Code Smell
        240. Functions shall not call themselves, either directly or indirectly

           Code Smell
        241. An assignment operator shall not assign the address of an object with automatic storage duration to an object with a greater lifetime

           Code Smell
        242. The "asm" declaration shall not be used

           Code Smell
        243. The target type of a pointer or "lvalue" reference parameter should be const-qualified appropriately

           Code Smell
        244. The "goto" statement shall jump to a label declared later in the function body

           Code Smell
        245. A "goto" statement shall reference a label in a surrounding block

           Code Smell
        246. The structure of a "switch" statement shall be appropriate

           Code Smell
        247. All "if ... else if" constructs shall be terminated with an "else" statement

           Code Smell
        248. The body of an "iteration-statement" or a "selection-statement" shall be a "compound-statement"

           Code Smell
        249. The result of an assignment operator should not be "used"

           Code Smell
        250. The comma operator should not be used

           Code Smell
        251. A cast should not convert a pointer type to an integral type

           Code Smell
        252. An object with integral, enumerated, or pointer to "void" type shall not be cast to a pointer type

           Code Smell
        253. A cast shall not remove any "const" or "volatile" qualification from the type accessed via a pointer or by reference

           Code Smell
        254. The "declaration" of an object should contain no more than two levels of pointer indirection

           Code Smell
        255. Parentheses should be used to make the meaning of an expression appropriately explicit

           Code Smell
        256. The names of the "standard signed integer types" and "standard unsigned integer types" should not be used

           Code Smell
        257. The same type aliases shall be used in all "declarations" of the same "entity"

           Code Smell
        258. A function or object with external linkage should be "introduced" in a "header file"

           Code Smell
        259. Block scope "declarations" shall not be "visually ambiguous"

           Code Smell
        260. A "header file" shall not contain definitions of functions or objects that are non-inline and have external linkage

           Code Smell
        261. Parentheses shall be used to ensure macro arguments are expanded appropriately

           Code Smell
        262. Function-like macros shall not be defined

           Code Smell
        263. "#undef" should only be used for macros defined previously in the same file

           Code Smell
        264. "#include" directives should only be preceded by preprocessor directives or comments

           Code Smell
        265. The lowercase form of "L" shall not be used as the first character in a literal suffix

           Code Smell
        266. Unsigned "integer literals" shall be appropriately suffixed

           Code Smell
        267. Octal constants shall not be used

           Code Smell
        268. A variable declared in an "inner scope" shall not hide a variable declared in an "outer scope"

           Code Smell
        269. Sections of code should not be "commented out"

           Code Smell
        270. The character sequence "/*" shall not be used within a C-style comment

           Code Smell
        271. "Trigraph-like sequences" should not be used

           Code Smell
        272. A named function parameter shall be "used" at least once

           Code Smell
        273. The value returned by a function shall be "used"

           Code Smell
        274. A value should not be "unnecessarily written" to a local object

           Code Smell
        275. Types with "limited visibility" should be "used" at least once

           Code Smell
        276. Variables with "limited visibility" should be "used" at least once

           Code Smell

        Parentheses should be used to make the meaning of an expression appropriately explicit

        intentionality - clear
        maintainability
        reliability
        Code Smell
        • confusing
        • misra-c++2023
        • misra-advisory

        Why is this an issue?

        More Info

        This rule is part of MISRA C++:2023.

        Usage of this content is governed by Sonar’s terms and conditions. Redistribution is prohibited.

        Rule 8.0.1 - Parentheses should be used to make the meaning of an expression appropriately explicit

        Category: Advisory

        Analysis: Decidable,Single Translation Unit

        Amplification

        The following table is used in the definition of this rule.

        Description

        Operator or Operand

        Ranking

        Other

        Any operator or operand not listed below

        14 (high)

        Multiplicative

        * / %

        13

        Additive

        + -

        12

        Bitwise shift

        << >>

        11

        Relational

        < > <= >=

        10

        Equality

        == !=

        9

        Bitwise AND

        &

        8

        Bitwise XOR

        ^

        7

        Bitwise OR

        |

        6

        Logical AND

        &&

        5

        Logical OR

        ||

        4

        Conditional

        ?:

        3

        Assignment

        = *= /= %= += -= <<= >>= &= ^= |=

        2

        Throw

        throw

        1

        Comma

        ,

        0 (low)

        The rankings used in this table are chosen to allow a concise description of the rule. They are not necessarily the same as those that might be encountered in the C++ Standard’s descriptions of operator precedence.

        Notes:

        • Operators having alternative token representations (see [lex.digraph]) have the same ranking as their primary form.
        • The additive row does not include unary plus and unary minus, which have rank 14.

        An expression is appropriately explicit when:

        • Its ranking is 0, 1, 2 or 14; or
        • Each operand:
        • Is parenthesized; or
        • Has a ranking of 14; or
        • Has ranking less than or equal to that of the expression.

        Additionally, the operand to the sizeof operator should be parenthesized.

        For the purposes of this rule, the ranking of an expression is the ranking of the element (operand or operator) at the root of the parse tree for that expression. For a sub-expression, its ranking is that of the element at the "root" of the sub-tree.

        For example, using the syntax and precedence rules from the C++ Standard, the parse tree for the non-compliant expression a << b + c can be represented as:

             <<
            /  \
           a    +
               / \
              b   c
        

        The element at the root of this parse tree is '<<', so the expression has ranking 11. The root of the sub-tree for b + c is +, which has ranking 12.

        Rationale

        The C++ language has a comparatively large number of operators and their relative precedences are not intuitive. This can lead less experienced developers to make mistakes. Using parentheses to make operator bindings explicit removes the possibility that the developer’s expectations are incorrect. It also makes the original developer’s intention clear to reviewers or maintainers of the code.

        It is recognized that overuse of parentheses can clutter the code and reduce its readability. However, too few parentheses can lead to unintuitive code. This rule tries to achieve a reasonable compromise.

        Note: this rule does not require the operands of a comma operator to be parenthesized, even though the result may not meet developer expectation. However, use of the comma operator is not compliant with M23_105: MISRA C++ 2023 Rule 8.19.1.

        x = a, b;   // Parsed as ( x = a ), b
        

        Example

        The following examples show expressions with a unary or postfix operator whose operands are either primary-expressions or expressions whose top-level operators have ranking 14:

        a[ i ]->n;               // Compliant - no need to write ( a[ i ] )->n
        *p++;                    // Compliant - no need to write *( p++ )
        sizeof x + y;            // Non-compliant - write either sizeof ( x ) + y
                                 // or sizeof ( x + y )
        

        The following examples show expressions containing operators of the same ranking:

        a + b - c + d;           // Compliant
        ( a + b ) - ( c + d );   // Compliant - produces a different result
        

        The following examples show a variety of mixed-operator expressions:

        x = f ( a + b, c );      // Compliant - no need to write f ( ( a + b ), c )
        
        x = a == b ? a : a - b;  // Non-compliant - operands of conditional operator
                                 // (ranking 3) are:
                                 //   == (ranking 9) needs parentheses
                                 //   a  (ranking 14) does not need parentheses
                                 //   -  (ranking 12) needs parentheses
        
        x = ( a == b ) ? a : ( a - b );   // Compliant version of previous example
        

        Note: the assignment operators in the previous two examples are compliant — the ranking of the assignment operator is less than 3, so its operands do not need parentheses.

        x = a << b + c;       // Non-compliant - operands of << operator
                              // (ranking 11) are:
                              //  a  (ranking 14) does not need parentheses
                              //  +  (ranking 12) needs parentheses
        
        a && b && c;          // Compliant - all operators are the same.
        a && b || c;          // Non-compliant - || (ranking 4) has operand && (ranking 5)
        a || b && c;          // Non-compliant - || (ranking 4) has operand && (ranking 5)
        a || b || c;          // Compliant - all operators are the same
        
        #if defined( A ) && defined( B ) || defined( C )  // Non-compliant
        

        Copyright The MISRA Consortium Limited © 2023

          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube ServerAnalyze code in your
          on-premise CI

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use